home *** CD-ROM | disk | FTP | other *** search
- Path: fido.asd.sgi.com!austern
- From: Max TenEyck Woodbury <mtew@cds.duke.edu>
- Newsgroups: comp.std.c++
- Subject: U.S. monitary unit.
- Date: 30 Jan 1996 19:39:35 PST
- Organization: Duke University Center for Demographic Studies
- Approved: austern@isolde.mti.sgi.com
- Message-ID: <4emnvr$ecu@news.duke.edu>
- NNTP-Posting-Host: isolde.mti.sgi.com
- X-Original-Date: 31 Jan 1996 03:34:18 GMT
- X-Mailer: Mozilla 1.1N (Windows; I; 16bit)
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBVAwUBMQ7kjky4NqrwXLNJAQH/UwH/RTFEALfqkvoADL/Fl+W/ToXt/Rha0Q9Y
- NwV+a8SiPnbKcDHLuIaCHuqgFxqqtJjIa0DLnVeHKvWyMqGeS7GaBw==
- =PuI2
- Originator: austern@isolde.mti.sgi.com
-
- I was just going through the draft standard locale section and noticed what
- might be a problem.
-
- The standard assumes that the unit of account is the cent or one hundreth
- of a dollar. Other units of account may be used, including the mil or one
- thousandth of a dollar. I suggest that there may be a requirement in some
- applications for internal values to be held in mils while display values be
- for some larger unit.
- There may be similar problems with international currencies.
-
- This problem would be handled easily if there were a monitary facet property
- that specified the size of the display unit in accounting units. This would
- have to be at least 'int' sized to allow accounts kept in mils to display
- whole dollars typically seen in tax preperation. In might be advisable to make
- it 'double' to take care of government economists who deal in 10^9 or 10^12
- dollar hunks.
-
- Max
- ---
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-